AWS W-A Framework 信頼性の柱をマインドマップ化してみた

コンバンハ、千葉（幸）です。

AWS Well-Architected フレームワークの信頼性の柱をマインドマップ化してみました。

マインドマップ

• 手元でツリーの開閉、拡大・縮小ができます
• 右上のアイコンから全画面表示ができます

このマップについて

上記のマップは以下のドキュメントのアウトラインを表したものです。

（PDF版）

ドキュメントの構成について

• 設計原則と定義が冒頭で示される
  • 設計原則はドキュメントのエッセンスを要約したもの
  • 定義は領域（分野とも訳される）と場合によってはその他の事項が示される
• 各領域のベストプラクティスが本文で記載されている
• 各領域は複数の階層からなる
• ドキュメントの記載の多くは AWS Well-Architected Tool の「質問」とチェック項目に対応する

マップの凡例について

• 赤塗りつぶしは AWS Well-Architected Tool の「質問」に相当する
• 黄色塗りつぶしは「領域」あるいはその一階層下の中項目を表す
• グレーアウトの箇所は AWS Well-Architected Tool に該当しないことを表す

詳細は以下エントリを参照してください。

本エントリのマップでは、上記エントリのマップより一階層下げた部分まで記載しています。

補足

マップ中央の直下の階層は各「領域（分野）」としており、以下のような順番で昇順となっています。

AWS Well-Architected フレームワーク 信頼性の柱

概要を記載します。便宜上、「領域（分野）」に番号を振っています。

設計原則

• 障害から自動的に復旧する
• 復旧手順をテストする
• 水平方向にスケールしてワークロード全体の可用性を高める
• キャパシティーを推測することをやめる
• オートメーションで変更を管理する

その他の定義

• 回復力、および信頼性のコンポーネント
  • 回復力
• 可用性
  • リクエストに基づいて可用性を測定する
  • ハードな依存関係を持つ可用性を計算する
  • 冗長コンポーネントの可用性を計算する
  • 依存するシステムの可用性を計算する
• 目標復旧時間と目標復旧時点
  • RTO
  • RPO

領域1. 基盤

• REL 1. Serviice Quotas の管理と制約
  • サービスクォータと制約を認識する
  • アカウントおよびリージョンをまたいでクォータを管理する
  • アーキテクチャを通じて、固定サービスクォータと制約に対応する
  • クォータをモニタリングおよび管理する
  • クォータ管理を自動化する
  • フェールオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する
• REL 2. ネットワークトポロジを計画する
  • ワークロードのパブリックエンドポイントに可用性が高いネットワーク接続を使用する
  • クラウド環境とオンプレミス環境のプライベートネットワーク間の冗長構成をプロビジョニングする
  • 拡張や可用性のために割り当てるIPサブネットを確保する
  • 多対多メッシュよりもハブアンドスポークトポロジを優先する
  • 接続されているすべてのプライベートアドレス空間において、重複しないプライベートIPアドレス範囲を指定する

領域2. ワークロードのアーキテクチャ

• REL 3. お客様のワークロードサービスアーキテクチャを設計する
  • ワークロードをセグメント化する方法を選択する
  • 特定のビジネスドメインと機能に重点を置いたサービスを構築する
  • APIごとにサービス契約を提供する
• REL 4. 障害を防ぐために分散システムでの操作を設計する
  • 必要な分散システムの種類を特定する
  • 疎結合の依存関係を実装する
  • すべての応答に冪等生を持たせる
  • 動作を継続的に行う
• REL 5. 障害を軽減または耐えるために分散システムでの操作を設計する
  • 該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装する
  • スロットルリクエスト
  • 再試行呼び出しを制御および制限する
  • すぐに失敗し、キューを制限する
  • クライアントタイムアウトを設定する
  • 可能な場合はサービスをステートレスにする
  • 緊急レバーを実装する

領域3. 変更の管理

• REL 6. ワークロードリソースをモニタリングする
  • 生成 - ワークロードのすべてのコンポーネントをモニタリングする
  • 集計 - メトリクスを定義して計算する
  • リアルタイムの処理とアラームの発行 - 通知を送信する
  • リアルタイムの処理とアラームの発行 - 対応を自動化する
  • ストレージと分析
  • 定期的にレビューを実施する
  • システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする
• REL 7. 需要の変化に適応するようにワークロードを設計する
  • リソースの取得またはスケーリング時に自動化を使用する
  • Amazon CloudFront または信頼できるコンテンツ配信ネットワークを設定して使用します
  • ワークロードの障害を検知した時にリソースを取得する
  • ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得する
  • ワークロードの負荷テストを実施する
• REL 8. 変更を実装する
  • デプロイなどの標準的なアクティビティにランブックを使用する
  • デプロイの一部として機能テストを統合する
  • デプロイの一部として回復力テストを統合する
  • イミュータブルなインフラストラクチャを使用してデプロイする
  • 自動化を使用して変更をデプロイする
  • リスクを最小限に抑えるための別のデプロイパターン
    • 機能フラグ
    • 障害を分離するためのゾーンでのデプロイ
    • 運用状況レビュー（ORR）

領域4. 障害の管理

• REL 9. データをバックアップする
  • バックアップする必要がるすべてのデータを特定してバックアップするか、ソースからデータを再現する
  • バックアップを保護し、暗号化する
  • データバックアップを自動的に実行する
  • データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する
• REL 10. 障害部分を切り離してワークロードを保護する
  • 複数の場所にワークロードをデプロイする
  • 単一のロケーションに制約されるコンポーネントのリカバリを自動化する
  • バルクヘッドアーキテクチャを使用する
• REL 11. コンポーネントの障害に耐えられるようにワークロードを設計する
  • ワークロードのすべてのコンポーネントをモニタリングしてエラーを検知する
  • 正常なリソースにフェイルオーバーする
  • すべてのレイヤーの修復を自動化する
  • 静的安定性を使用してバイモーダル動作を防止する
  • イベントが可用性に影響する場合に通知を送信する
• REL 12. 信頼性をテストする
  • プレイブックを使用して失敗を調査する
  • インシデント後の分析を実行する
  • 機能用件をテストする
  • スケーリングおよびパフォーマンス用件をテストする
  • カオスエンジニアリングを使用して回復力をテストする
  • 定期的にゲームデーを実施する
• REL 13. 災害対策（DR）を計画する
  • ダウンタイムやデータ消失に関する復旧目標を定義する
  • 復旧目標を満たすため、定義された復旧戦略を活用する
  • バックアップと復元
  • パイロットライト
  • ウォームスタンバイ
  • マルチリージョンのアクティブ/アクティブ
  • 災害対策の実装をテストし、検証する
  • DRサイトまたはリージョンでの設定ドリフトを管理する
  • 復旧を自動化する

可用性目標の実装例

• 単一リージョンのシナリオ
• 複数リージョンのシナリオ

参考